Database schemas are metadata that define a structure for data stored in a database. In essence, database schemas are a contract between client applications and a database system. In many cases, the client systems that utilize such databases are not monolithic. Rather, they are built by composing together libraries and other types of components. Often, however, these components are not created by the developer of the client application. Consequently, if the components require database access, they typically provide an abstract interface to access the database. Clients then implement these interfaces to provide the components access to the database. Shared components can also be built as separate services that operate outside the process space of the client application.
There are, however, limitations to both of the models described above. For example, if database access is abstracted out, then a component cannot efficiently provide a prescription for the internal layout of the database. A designer of a shared component would like to do this to ensure that data in the database is laid out in a way that provides efficient data access to the shared component. From the perspective of the client, however, the shared component is a black box and, therefore, the client might not be the best party to suggest a data layout on behalf of the designer of the shared component.
When the component is built as a network service, the modifications to the database by both the client application and shared component cannot be done in the same transaction. One remedy for this shortcoming is to build a distributed transaction protocol implementation. Such an implementation is, however, costly to operate and maintain, and can hit scaling limits quickly.
The disclosure made herein is presented with respect to these and other considerations.